Skip to content

ctutils v0.4.4 - #1569

Merged
tarcieri merged 1 commit into
masterfrom
ctutils/v0.4.4
Oct 23, 2026
Merged

tarcieri merged 1 commit into
masterfrom
ctutils/v0.4.4

Conversation

@tarcieri

Copy link
Copy Markdown
Member

Security

  • Fix and verify Choice::to_*_mask constant-time codegen (#1567)
  • Fix constant-time u128 comparisons on 32-bit targets (#1568)

@tarcieri
tarcieri merged commit a993c0b into master Oct 23, 2026
148 checks passed
@tarcieri
tarcieri deleted the ctutils/v0.4.4 branch October 23, 2026 01:03
tarcieri added a commit to RustCrypto/crypto-bigint that referenced this pull request Oct 23, 2026
This release includes important security fixes: RustCrypto/utils#1569
djc pushed a commit to rustsec/advisory-db that referenced this pull request Oct 23, 2026
This advisory covers issues fixed in v0.4.4:

RustCrypto/utils#1569
thomaseizinger added a commit to firezone/firezone that referenced this pull request Oct 23, 2026
Versions of `ctutils` before 0.4.4 can generate branches in the mask
generation of `Choice` on common platforms, and in its `u128`
comparisons on 32-bit targets, so they are not constant-time. This is a
new advisory that fails `cargo deny` on every PR.

Related: RustCrypto/utils#1569
CueCrux-Myles pushed a commit to CueCrux/Crux that referenced this pull request Oct 23, 2026
ctutils < 0.4.4 has non-constant-time mask generation and u128
comparisons (RustCrypto/utils#1569). It reaches the tree through
p256/ecdsa/hmac and turns Cargo deny red on every branch. Lockfile-only;
ctutils 0.4.5 needs Rust 1.87, inside the current MSRV.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011G8hmqqwypRjci676mqZ6Z
CueCrux-Myles pushed a commit to CueCrux/Crux that referenced this pull request Oct 23, 2026
ctutils < 0.4.4 has non-constant-time mask generation and u128
comparisons (RustCrypto/utils#1569). It reaches the tree through
p256/ecdsa/hmac and turns Cargo deny red on every branch. Lockfile-only;
ctutils 0.4.5 needs Rust 1.87, inside the current MSRV. The same bump
rides #834, so whichever lands first carries it to main.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011G8hmqqwypRjci676mqZ6Z
kunwarshivam pushed a commit to kunwarshivam/mandate that referenced this pull request Oct 23, 2026
`cargo deny --locked check` fails on main. In ctutils 0.4.2, the constant-time
`Choice` mask lacked an optimization barrier (RUSTSEC-2026-0385,
RustCrypto/utils#1569); 0.4.4 and later fix it. ctutils is a transitive
RustCrypto crate, reached through aes-gcm, crypto-bigint, digest, sec1 and
universal-hash (webpush, p256, sqlx-postgres). `cargo update -p ctutils` makes
a patch-level bump. Nothing else in Cargo.lock moves, and no manifest or
dependency row changes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UoxcMViCbnGUTPSaduuGYU
kunwarshivam added a commit to kunwarshivam/mandate that referenced this pull request Oct 23, 2026
…s for RUSTSEC-2026-0385 (DEC-2334, DEC-2338) (#2322)

* CI (lane GO): run api-release in a full-checks-3 job of its own (DEC-2334, DEC-2338)

#2289 added `api-release` to `cargo xtask ci full` (DEC-2338 item 5) after
#2195 had split `full`'s parts into `full-checks` and `full-checks-2`
(DEC-2334). No CI job ran `api-release`, and
`the_full_jobs_run_exactly_the_full_group` failed on main.

Its release build of `mandate-api-server` takes about five minutes on its own.
Neither existing job has room for that under ten minutes (DEC-464):
`full-checks-2`'s `reference` alone is about 4.5 minutes, before its two
release builds. So it runs in `full-checks-3`, on the same selection, and
`full` needs all three. The verdict table now shows a failed, cancelled or
skipped `full-checks-3` failing `full`.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UoxcMViCbnGUTPSaduuGYU

* Supply chain: bump ctutils 0.4.2 -> 0.4.5 for RUSTSEC-2026-0385

`cargo deny --locked check` fails on main. In ctutils 0.4.2, the constant-time
`Choice` mask lacked an optimization barrier (RUSTSEC-2026-0385,
RustCrypto/utils#1569); 0.4.4 and later fix it. ctutils is a transitive
RustCrypto crate, reached through aes-gcm, crypto-bigint, digest, sec1 and
universal-hash (webpush, p256, sqlx-postgres). `cargo update -p ctutils` makes
a patch-level bump. Nothing else in Cargo.lock moves, and no manifest or
dependency row changes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UoxcMViCbnGUTPSaduuGYU

---------

Co-authored-by: Claude <noreply@anthropic.com>
This was referenced Oct 24, 2026
DioCrafts pushed a commit to AtalayaLabs/OxiCloud that referenced this pull request Oct 24, 2026
RUSTSEC-2026-0385 — "Non-constant-time mask generation and `u128`
comparisons" (RustCrypto/utils#1569), published 2026-10-23. Fixed in
>= 0.4.4; the lockfile resolves to 0.4.5.

Transitive, and reached by two independent paths — worth noting because
dropping the S3 SDK would not have removed it:

  ctutils -> digest 0.11.3 -> {sha2, hmac, md-5, sha1}
    - sha2 / md-5: direct oxicloud dependencies
    - hmac / sha1: via aws-sdk-s3, aws-sigv4, aws-smithy-checksums

`cargo update -p ctutils` moved exactly one package; no other
dependency shifted.

Exposure is the constant-time guarantee of the digest primitives, so
the relevant callers are the ones handling secrets or
attacker-influenced bytes: password/token hashing paths and S3 request
signing. The advisory is a weakening of timing resistance rather than a
correctness bug, so no behaviour changes — but per AGENTS.md security is
an absolute axis, not a trade-off, which is why this goes in on its own
rather than riding along with the next feature branch.

cargo audit: exit 0, zero ctutils findings. The 11 remaining entries are
the pre-existing allowed warnings (unmaintained/yanked: paste,
http-types, spin, basic-toml, smallstr, ttf-parser, event-listener, lru,
…) and are untouched by this change.

clippy --all-features --all-targets: 0 warnings.
cargo test --workspace: 1277 passed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
EugeneTeplitsky added a commit to WishKnish/KnishIO-Client-Rust that referenced this pull request Oct 24, 2026
What:
- Cargo.lock: ctutils 0.4.2 -> 0.4.4 (lock only, 2 lines: version and
  checksum), for RUSTSEC-2026-0385 (non-constant-time mask generation
  and u128 comparisons, published 2026-10-23). Reaches the crate
  through aes-gcm 0.11.1 and digest 0.11.3. Cargo.toml is unchanged.
- CHANGELOG.md: Security entry under [2.2.0] before the 2.2.0 tag is
  created.

Why:
- cargo audit against the committed Cargo.lock reported
  RUSTSEC-2026-0385 (CI's audit job resolves a fresh lockfile, which
  masked it on 8f99bbb, while --locked builds in test-kcore and the
  edge/validator kits read the committed lock).

Cooldown-valve exception:
- ctutils 0.4.4 was published 2026-10-23T01:04:28Z by tarcieri, a
  crates.io owner of ctutils (owners: tarcieri,
  github:rustcrypto:utils), in RustCrypto/utils#1569, and is the oldest
  release that fixes RUSTSEC-2026-0385. OSV query for 0.4.4: 0
  advisories. Lock checksum
  12218662ccac37d9714f2191252553d67585b97df8c839cbe49e0bde278dc865
  equals the crates.io index cksum, and its normal dependencies are
  unchanged from 0.4.2 (cmov ^0.5.3).

How verified:
- cargo audit: exit 0, 0 vulnerabilities, 2 allowed warnings.
- KNISHIO_KCORE_DIR=<kcore 0.2.0 darwin-universal> cargo test --locked
  --features kcore,parallel: 698 passed, 0 failed (cross_platform 24,
  ots_v2 7, patent 13, served_molecule 9, version4_hash 13,
  concurrent_verification 2).
- Cargo.lock diff is 2 lines (ctutils version and checksum only).

Not run:
- Live/testnet tests (cipherhash_live, ots_migration_live ignored).
ghbvf added a commit to shengming0817/rss-identity that referenced this pull request Oct 25, 2026
Resolve RUSTSEC-2026-0385 with ctutils 0.4.4, keeping the remainder of the dependency graph unchanged.

ref: RustCrypto/utils ctutils RustCrypto/utils#1569
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant